IBIS Macromodel Task Group Meeting date: 18 October 2016 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM * Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki * Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Walter noted that he was interested in talking about allowing the use of relative paths in locating supporting files for an IBIS file. ------------- Review of ARs: - Bob Ross to send out an updated BIRD 147.2 proposal containing the changes discussed. - Done. A further updated version, BIRD 147.3, was sent out after a post-meeting email discussion amongst several attendees. - Mike LaBonte to submit BIRD 147.3 to the Open Forum. - Done. - Michael Mirmak to draft a clarification BIRD for AMI Output parameters. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Radek: Motion to approve the minutes. - Walter: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: - Arpad: Anything else to discuss on BIRD 147.2 or 147.3? - Bob R.: BIRD 147.3, as submitted to the Open Forum, is all set. - Mike L.: I think technically it is now out of this committee. - There was no real controversy over it when it was introduced at the Open Forum last Friday. - I think it can be off the ATM agenda for now, unless the Open Forum asks for some more input. - Bob: There is one bigger picture issue that came up, which might be taken care of in another BIRD. - The BCI_ID definition contains the language "alphanumeric identifier", similar to the language for the AMI Reserved parameter DLL_ID. - That's an issue for the future, as we might want to relax the "alphanumeric" requirement and allow the full character set allowed for filenames [See Section 3, item 3. of the IBIS spec.]. - Walter: BCI_ID contains a unique name created by the EDA tool. - It's not created by the model maker (maker of the .ami file). - I agree that it might be over-constrained, but I don't think it's a problem. - We can relax it in the future if we want to, but it's not causing any trouble. - Bob: We might flag a legal file name character as an error in the parser? - Walter/Ambrish: No the parser doesn't see this value, it's set at runtime by the EDA tool. - Bob: What about the default value in the .ami file? - Would "no_name" as a default value be flagged? I'm not sure. - Radek: The values in the .ami file for BCI_ID and DLL_ID are just place- holders that can be completely ignored. - Bob: Okay, the bottom line is that BIRD147.3 is okay as is. - In the future, we may want to look at whether we should relax that statement that the values of those parameters have to be alphanumeric. Bob Ross and Radek's discussion of Editorial Task Group Issues: - Bob: We reviewed what we agreed upon. - These have been stated before: - We have the "node collapse" rule where if all the corner values for two [* Reference] keywords are the same, then their corresponding terminals are considered the same (shorted). - We prefer "simulation model" vs. DIA (device in action). - We recommend [Local Reference] as another reference keyword. - Its primary function is to provide the node for the default C_comp or Package connections. - We discussed a [DUT Reference] and its node, which provides the reference for extraction of IBIS model information. - We discussed a notion of a simulation reference, which is where the [Local Reference] is connected. - We agreed that with [Local Reference] we would not change the I-V tables. But we could measure I/O buffer outputs with respect to a simulation reference. - Next steps are to document what we agreed upon. - Somehow insert the "node collapse" rule into the spec. - It could be part of an expanded version of BIRD 181.1, or it could be in a BIRD related to the [* Reference] voltages. - I've added an expanded draft of touchstone vs. IBIS-ISS. - Touchstone files in general leave the circuit topology ambiguous. - If you assume an n+1 reference node, the topology becomes more fixed. - IBIS-ISS you nail down the topology with the available nodes right away. - We've tentatively planned our next meeting for Wednesday afternoon. Relaxation of IBIS filename restrictions: - Walter: [sharing Section 3, item 3., which defines filename requirements] - Primary items: lower case, 40 character max, 3 character extensions. - This was quite good 20 years ago, and it made sense because it made it simpler to move amongst UNIX/Windows/DOS. - I'd like to extend these now. - Why not have more than 40 characters? - Why limit ourselves to lower case? - Why limit ourselves to 3 character extensions? - For example, if I had an xyz.s10p S parameter filename, that's a four character extension. - Arpad: That's a good point. - In IBIS-ISS we allow touchstone filenames, do these rules apply to IBIS-ISS touchstone filenames as well? - Walter: I'm not sure. - Bob: We haven't changed the rules, and it's ambiguously stated, but they are technically limited to the IBIS defined file types themselves (.ami, .ebd, .ibs, .pkg). We actually define those 3 character extensions. - Walter: It says [in Section 3, item 3.], "file names used in a .ibs file". - So we have .iss files, touchstone files, etc. - Bob: I think it's ambiguous. - Walter: I just think we should consider relaxing these requirements. - Moving further, should we allow filenames like "base/file.xyz"? - In the future we may have a large number of files that go along with a .ibs file, or go along with a .pkg or interconnect model set. - It would be nice to put them all in a directory. For example, one sub- directory to hold all the S parameter models called by an interconnect model set, etc. - I think we should consider allowing relative paths. - Bob: I understand and agree that we could do something like this with a BIRD. - But there's a difference between what we say in the spec and what an EDA vendor might do moving the files around. - The issue is, if the EDA tool uses the official parser, can we even check the set of files if they get moved around to different locations? - Mike L.: That's irrelevant. - We only need to specify how the files are delivered by the model maker. - The parser only needs to parse things based on the IBIS rules we describe. After delivery, it's not the parser's problem. If the EDA tool rearranges things after that, it's up to the EDA tool to get it right. - Walter: Today all the files have to be in the same directory. - I think it would be a major improvement to allow files to be in subdirectories. - If an EDA tool wants to move all the files off into some different structure, then they may need to modify the official parser. - Or we could change the official parser and let it go off and find any files it needs in the subdirectories of the one containing the .ibs file. - Arpad: Subdirectories make sense in some cases. - But in other cases the parent directory might also make sense, for example, if you want to have a bunch of common files that are used by many different models or different versions of the same model. - Walter: That would be fine. - If the IBIS file calls out a certain location for something, say a .dll in a subdirectory, then if the tool moves that .dll somewhere it could potentially modify the .ibs file if it wanted to keep the parser happy. - I would just like people to think about it and see if you can think of anything bad that would happen if we allow an IBIS file to be delivered with its support files in subdirectories of the IBIS file. - Arpad: That's not a bad idea for organization. - If we say that all these rules matter only for initial delivery purposes, and the tool can then do whatever it wants, then is this that big a deal? - Walter: I don't think it's that big a deal. - What could happen is if the tool moves things around it could break other dependencies, but as long as it knows what to move around it should be okay. - Mike L: We have that pretty well covered. - How and what to move around is pretty well covered by the AMI Reserved parameter Supporting_Files. - Walter: Okay, think about this idea of allowing subdirectories. It may not be as general as everyone might like, but can anyone think of any bad things that would happen? - Bob: That's a good suggestion, and we could vet it through the BIRD process. - This is where I brought up the expanded character set earlier. We currently don't allow "/", for example, which would be the directory separator in some operating systems. We could deal with that in the BIRD, too. - What about the case sensitivity? I understand it for Linux, but it could create a filename collision for Windows, which doesn't recognize case differences in file names. - Mike L.: But having that provision in IBIS amounts to what a lawyer would call prior restraint. - If a model maker is making any files that will ever land on a Windows system then they know they would run into this problem. - That's a standing issue with Windows. - I don't think IBIS needed to take it upon itself to protect people from themselves. - Bob: The parser only checks the [File Name] keyword for lower case only. - The actual file could differ by having some upper case letters and the parser would not complain about that. - Arpad: I personally like to use capitalization to indicate word boundaries instead of underscore or something like that. - So I would like to have capital letters, even though I'm not using them to represent unique filenames vs. lowercase. - Walter: Also, would we like to have a filename like this: xyz.def.jklm ? - "." is not in our current character set, but I think this filename should be valid. - Walter: I don't think anyone here objects to the idea. - I would like to take a cut at rewriting this paragraph. - If we can then come to agreement on it, then we can draft a BIRD. - Ambrish: What's the rationale for having the [File Name] keyword inside the IBIS file that has to match the actual file name? - Arpad: It was just for sanity checking. - Mike L.: It actually comes out of the early days of email. - In the days before email attachments were common, the entire IBIS file was in the contents of the email. The [File Name] field gave you the actual name of the file. - Walter: We could make it optional in some future release. - Bob: Or we could add a similar keyword for AMI files. - Ambrish: I'd like to just get rid of it. - Bob: It doesn't hurt anything. - Ambrish: It does, if I change the name of a file without adjusting that [File Name] then the parser complains. - Arpad: In a case where one IBIS file refers to another, then if someone changes a file name the parser might not be able to find it. I guess then this keyword might be useful for finding out the real file name? - Walter: I sense everyone here is okay with improving this to make file names more readable and more general. - I will take a cut at rewriting this section. - Radek: Good. If we consider an extension to allow "/" to be used for subdirectories then we can discuss that, too. - Ambrish: Motion to adjourn. - Radek: Second. - Arpad: Thank you all for joining. AR: Walter to draft an updated version of IBIS file name rules. ------------- Next meeting: 25 October 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives